Description

Fix cancel_stream settlement semantics so cancellation proactively pays the recipient's final claimable amount, refunds remaining balance to sender, and deactivates the stream consistently.

Closes #199

Changes proposed

What were you told to do?

I was asked to implement cancel_stream so it:

• verifies caller is stream sender,
• pays final claimable amount to recipient,
• refunds remaining deposited amount to sender,
• marks stream inactive.

What did I do?

Updated cancel_stream token settlement logic

In contracts/stream_contract/src/lib.rs:

• kept sender auth/ownership checks and inactive guard,
• calculates accrued claimable amount at cancel time,
• transfers accrued amount to recipient immediately,
• updates withdrawn_amount to include the recipient settlement,
• refunds only the true remaining balance to sender,
• sets is_active = false and persists stream state.

Updated tests for new cancellation behavior

In contracts/stream_contract/src/test.rs:

• test_cancel_stream_refunds_sender now asserts recipient receives accrued amount on cancel and contract balance goes to zero,
• test_cancel_stream_after_partial_withdrawal now asserts recipient final balance includes cancel-time settlement and contract drains to zero,
• withdrawn_amount assertions updated to match proactive recipient payout.

Check List (Check all the applicable boxes)

• My code follows the code style of this project.
• This PR does not contain plagiarized content.
• The title and description of the PR is clear and explains the approach.
• My commit messages styles matches our requested structure.
• My code additions will fail neither code linting checks nor unit test.
• I am only making changes to files I was requested to.

Screenshots / Testing Evidence

Attempted validation:

cargo test -p stream_contract

Test build currently fails due existing upstream test compile issues unrelated to this PR (stream_id1/stream_id2/token_address unresolved in pre-existing tests).